為什麼要重新設計後端架構？

在四年的接案經驗中，我使用了各種後端技術組合：Python FastAPI、Kotlin Spring Boot、Go Gin、Node.js Express。每個專案都是獨立開發，導致：

• 技術棧分散：每個專案需要不同的開發環境和部署方式
• 邏輯重複：認證、授權、驗證邏輯在各專案中重複實作
• 維護困難：bug 修復需要在多個專案中同步處理
• 無法擴展：客戶需求變化時，需要重新評估整個技術架構

加上去年開了工作室，也該是時候打造屬於工作室的SaaS產品，從而擺脫各種客製化的服務，可以推出一套SaaS產品來尋找機會。

因此決定建立統一的 Kyo-System 後端架構，採用微服務策略，從 OTP 驗證服務開始，逐步建立完整的 SaaS 平台。

Kyo-System 後端整體架構

後端採用clean architecture與事件驅動設計：

┌─────────────────────────────────────────────────────────────────────┐
│                    KYO-SYSTEM BACKEND ARCHITECTURE                 │
└─────────────────────────────────────────────────────────────────────┘
                                    │
┌─────────────────────────────────────────────────────────────────────┐
│                         API GATEWAY LAYER                          │
│                      TypeScript + Fastify                         │
│              • REST (External) • ORPC (Internal)                  │
└─────────────────────────────────────────────────────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
        ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
        │   AUTH SERVICE  │ │  GYM SERVICE    │ │ BOOKING SERVICE │
        │                 │ │    (Future)     │ │    (Future)     │
        │ • OTP Logic     │ │ • Member Mgmt   │ │ • Class Booking │
        │ • Template Mgmt │ │ • Trainer Info  │ │ • Schedule      │
        │ • Rate Limiting │ │ • Access Control│ │ • Payments      │
        └─────────────────┘ └─────────────────┘ └─────────────────┘
                    │               │               │
                    └───────────────┼───────────────┘
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                        SHARED SERVICES                            │
├─────────────────┬─────────────────┬─────────────────┬──────────────┤
│  Core Business  │  Data Access    │  Event System   │  External    │
│  • @kyong/kyo- │  • Prisma ORM   │  • Redis Streams│  • Mitake SMS│
│    core         │  • Repositories │  • Pub/Sub      │  • Payment   │
│  • Validators   │  • Migrations   │  • Event Store  │  • Analytics │
└─────────────────┴─────────────────┴─────────────────┴──────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                       DATA & CACHE LAYER                          │
├─────────────────┬─────────────────┬─────────────────┬──────────────┤
│  RDS PostgreSQL │  ElastiCache   │  Redis Streams  │  S3 Storage  │
│  • OTP Logs     │  • Rate Limits  │  • Events       │  • Files     │
│  • Templates    │  • OTP Cache    │  • Pub/Sub      │  • Backups   │
│  • Users        │  • Sessions     │  • Dead Letter  │  • Logs      │
└─────────────────┴─────────────────┴─────────────────┴──────────────┘

技術棧選型策略

為什麼選擇全 TypeScript 微服務？

TypeScript + Fastify

• ✅ 型別安全：編譯時檢查，減少執行時錯誤
• ✅ 效能優異：Fastify 是最快的 Node.js 框架之一
• ✅ 生態豐富：豐富的 plugin 生態系統
• ✅ 輕量架構：相較於 NestJS 更輕量，學習成本低

Prisma ORM

• ✅ 型別安全：自動生成 TypeScript 型別
• ✅ 遷移管理：版本化的資料庫 schema 管理
• ✅ 查詢優化：自動產生最佳化 SQL

Redis + Redis Streams

• ✅ 多用途：快取、session、rate limiting、事件流
• ✅ 事件驅動：Redis Streams 提供可靠的事件處理
• ✅ 水平擴展：叢集模式支援
• ✅ 持久化：資料持久化與災難恢復

ORPC (內部) + REST (外部)

• ✅ 雙重介面：內部型別安全，外部標準相容
• ✅ 開發效率：ORPC 提供函式級別的型別檢查
• ✅ 向後相容：REST API 保持穩定，支援多語言客戶端